Date: Sat, 11 Dec 93 04:30:26 PST
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #143
To: Ham-Digital


Ham-Digital Digest          Sat, 11 Dec 93       Volume 93 : Issue  143

Today's Topics:
                          1933 vs. 1935 HDLC
                9k6 baud packet - is there any point?
                    COMPLETE Documented NOS Wanted
                           Digital Cellular
                     HP48 Communications (2 msgs)
          Need advice on using tube-final rigs for RTTY/AFSK
                      NETMGR a tool for R.O.S.E.
                           Scrambler lockup
                  W9GR DSP article of Sept 1992 QST
                           X1J at 38.4 kbps

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 9 Dec 1993 05:35:17 GMT
From: news.Hawaii.Edu!tony@ames.arpa
Subject: 1933 vs. 1935 HDLC
To: ham-digital@ucsd.edu

What is the difference between a WD 1933 and a WD 1935?  I notice that the 
manual/schematic for some TNC-1 clones show a 1933 but when you pop the thing
open there's a 1935 in there.
-- 
Antonio Querubin  
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet

------------------------------

Date: 10 Dec 1993 11:10:25 -0600
From: mvb.saic.com!unogate!news.service.uci.edu!usc!howland.reston.ans.net!gatech!concert!corpgate!crchh327.bnr.ca!debaker@network.ucsd.edu
Subject: 9k6 baud packet - is there any point?
To: ham-digital@ucsd.edu

In article <755446538snx@llondel.demon.co.uk>, dave@llondel.demon.co.uk (David Hough) writes:
|> In article <FROUD.93Dec8202731@sunlab41.sx.ac.uk> froud@sunlab41.sx.ac.uk (How much wood could a woodchuck chuck if a woodchuck could chuck wood?) writes:
|> >Just a minor point I wouldn't mind cleared up if anyone has a few seconds...
|> >
|> >I read that rigs had to be modified to allow upwards of 2k4 baud transmission,
|> >but is this pointless if the person you are trying to commmunicate with
|> >hasn't a repicrocal modification at the either end to allow reception of
|> >higher baud transmissions?
|> >
|> Unlike land-line modems, there is no speed negotiation on packet (unless you
|> are using strange kit) so you have to set up your rig/TNC to work at a 
|> particular speed. Once you have tried 9600baud you will think that 1200 is
|> *very* slow. It isn't hard to modify rigs either....

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OK, now I am ready to get some info on modifying rigs for 9600!  I have a 
kenwood TM-742A that I would like to use...does anyone know where I can find
information explaining how to do this?

Also, how do I go about finding a 'full sevice PBBS' (if that is what I am
looking for) in order to send long distance packet mail, i.e. to an address
of a person in another city or state (or country)??

|> 
|> Dave
|> -- 
|> 
|> *****************************************************************************
|> * G4WRW @ GB7WRW.#41.GBR.EU AX25     *    Start at the beginning. Go on     *
|> * dave@llondel.demon.co.uk  Internet *     until the end. Then stop.        *
|> * g4wrw@g4wrw.ampr.org      Amprnet  *      (the king to the white rabbit)  *
|> *****************************************************************************

Thanks,
73,
____________________________________________________________
| David E. Baker                    Opinions expressed are |
| Callsign: AB5PI                   mine, and they do not  |
| Internet: debaker@bnr.ca          necessarily reflect    |
| IP Addr:  47.122.65.7             the opinions of BNR or |
| Unix ID:  crchh7b0                or Northern Telecom.   |
|----------------------------------------------------------|

------------------------------

Date: Wed, 8 Dec 1993 18:32:12 GMT
From: nih-csl!helix.nih.gov!mack@uunet.uu.net
Subject: COMPLETE Documented NOS Wanted
To: ham-digital@ucsd.edu

In article <9312012304.tn22729@aol.com> <mattharvey@aol.com> writes:
>I would like to know how I could attain a copy of the latest version of KA9Q
>unmodified NOS. I would appreciate it if I could find a package with complete
>documentation that includes the file BM.EXE. Please send responses to
>MattHarvey@aol.com OR KD4AZH@KB4GBS.#TPA.FL.US.NOAM.
>
>Thank you.
Do you know about the book from tthe ARRL (forget what it's called -
comething like NOSGUIDE). Unfortunately it's pitched at a very 
low level.
 Joe NA3T
 mack@ncifcrf.gov

------------------------------

Date: Wed, 08 Dec 93 12:49:04 MST
From: pacbell.com!sgiblab!swrinde!cs.utexas.edu!asuvax!ennews!stat!aznet!dan@network.ucsd.edu
Subject: Digital Cellular
To: ham-digital@ucsd.edu

We are currently running Digital in our system,  but it is still undergoing
testing and is not accessible by the public just yet.  We are testing the
format of CDMA.


Dan

----------------------
  dan@aznet.stat.com
  Daniel J. Meredith
  Fax - (602) 956-2566
Voice - (602) 809-0555

------------------------------

Date: 10 Dec 1993 08:39:06 -0600
From: mvb.saic.com!unogate!news.service.uci.edu!usc!cs.utexas.edu!swrinde!gatech!news-feed-1.peachnet.edu!concert!corpgate!crchh327.bnr.ca!kharker@network.ucsd.edu
Subject: HP48 Communications
To: ham-digital@ucsd.edu

In article <jann0004-091293230819@dialup-1-75.gw.umn.edu>, jann0004@maroon.tc.umn.edu (Scott Jann) writes:
|>   I am looking for a cheap way to communicate between two HP-48 calculators
|> (longer than the build in IR can do), maybe 50-100 feet.  I have heard of
|> people modifying walkie-talkies to use with the hp48.  I don't want to use
|> TNC equipment....too expensive for me.
|>   How would I go about modifying a walkie-talkie to do digital
|> communications?  I don't care about error checking or anything, just a way
|> to send simple ascii messages.
|>   Can anyone help me with doing this?
|> 
|> Thanks

     As another idea, I have seen infrared "repeaters"  little red pyramid-shaped
things that relay the signals of tv remotes and whatnot.  Perhaps a strategically
placed one (if you're going to be using the calculators basically in the same area
all the time) would do the trick.  Don't know where you'd go to find one of these
things.  Probably saw it in a Damark catalog or someplace like that.

-- 
======================================================================
Kenneth E. Harker             BNR              "Any opinions expressed
 kharker@bnr.ca      Richardson, Texas, USA     are solely mine and do
     N1PVB               (214) 684-5115         not represent BNR"
======================================================================

------------------------------

Date: Fri, 10 Dec 1993 05:12:47 GMT
From: pacbell.com!sgiblab!swrinde!cs.utexas.edu!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!umn.edu!dialup-1-75.gw.umn.edu!user@network.ucsd.edu
Subject: HP48 Communications
To: ham-digital@ucsd.edu

  I am looking for a cheap way to communicate between two HP-48 calculators
(longer than the build in IR can do), maybe 50-100 feet.  I have heard of
people modifying walkie-talkies to use with the hp48.  I don't want to use
TNC equipment....too expensive for me.
  How would I go about modifying a walkie-talkie to do digital
communications?  I don't care about error checking or anything, just a way
to send simple ascii messages.
  Can anyone help me with doing this?

Thanks

------------------------------

Date: Thu, 9 Dec 1993 16:50:30 GMT
From: pravda.sdsc.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv!gary@network.ucsd.edu
Subject: Need advice on using tube-final rigs for RTTY/AFSK
To: ham-digital@ucsd.edu

In article <CHqHJ9.Awz@srgenprp.sr.hp.com> alanb@sr.hp.com (Alan Bloom) writes:
>Patric M Stickler (stickler@klaava.Helsinki.FI) wrote:
>: How can one
>: estimate the max. drive the finals can take at 100% duty cycle? 
>
>If the rig has an AM mode, use the AM carrier power rating.

Good.

>Even better, mount a 3 or 5-inch muffin fan on the side of the cabinet
>blowing directly on the final amplifier tubes.  With that, you should
>be able to run full CW power on digital modes.  The main limitation then
>will be the power transformer -- As long as you keep the transmit time
>below 50% (at least 50% listening time), you should be OK.

Not so good. The limitation isn't usually raw envelope temperature, it's
the temperature of the plate structure and the seals at the connections.
With sweep tubes, you can't cool them effectively enough with a muffin fan 
to get even 50% power, much less 100% power when key down time exceeds a
few seconds. The plate structures aren't up to it, and you need to get 
airflow across the base seals, and they're masked by the tube socket.
Real transmitting tubes are better because their plate structures are
heavier, but you still have seal problems unless you have air sockets.
Best, of course, are external anode tubes mounted in proper air sockets
with proper chimneys.

Low duty cycles are good, but you still have to watch absolute key
down times. If the key down time exceeds the thermal inertia of the
tube, you've got to treat it like it's 100% duty cycle use.

Gary
-- 
Gary Coffman KE4ZV          | I kill you,             | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems | You kill me,            | uunet!rsiatl!ke4zv!gary
534 Shannon Way             | We're the Manson Family | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |         -sorry Barney   | 

------------------------------

Date: 7 Dec 1993 22:45:42 -0500
From: kb2ear.ampr.org!not-for-mail@princeton.edu
Subject: NETMGR a tool for R.O.S.E.
To: ham-digital@ucsd.edu

Bill Slack NX2P asked me to post this. 

NETMGR is a Windows based ROSE network managment took.  It
allows the ROSE network manager or switchOP to graphically
draw the network (or part of the network) and automatically
generate the configuration files.  In most cases no manual
editing of the configuration files will be neccessary.

If you would like a copy and don't have FTP please send me email and I
send a copy via email.  Or I'll post somewhere on USENET. 

What FTP sites should I post this on?


If you would like more info about ROSE send email to
askrat@kb2ear.ampr.org and/or get on the ROSE mailing list.  To get on
the mailing list send email to listserv@kb2ear.ampr.org with this line
as the body:

ADD rose

or

ADD <Your_Address> rose

To post to the list send email to rose@kb2ear.ampr.org.

73,
-- 
Scott R. Weis KB2EAR
Internet: kb2ear@kb2ear.ampr.org
Snail Mail: 10 Palmer Rd., Kendall Park, NJ, 08824-1228
Phone:  +1 908 297 0469

------------------------------

Date: 11 Dec 93 05:55:25 GMT
From: news-mail-gateway@ucsd.edu
Subject: Scrambler lockup
To: ham-digital@ucsd.edu

Here in Utah, we have designed and run some test on a T1 radio modem.

The modem appears to work very well but there is an area of slight concern:
This modem uses a 17 bit maximal-length scrambler (taps on bits 5 and 17).

This scrambler uses the same circuit topography as the scrambler in the GRAPES
modem and uses 2 XOR gates (74HC86) 2 shift registers (2 74HC164's) and 
a flip-flop (1/2 of a 74HC74).

The problem seems to be that there some unsusal circumstances (cause unknown)
in which the scrambler seems to get "stuck".  Since this sequence generator
is obstensively an open loop system (as opposed to a PN generator used for
Spread Spectrum) I don't see how this should be able to occur, but occur
it can.

Has anyone else had experience with this sort of scrambler and had to deal
with this problem?

Several things come to mind:  On could detect the lack of appropriate
transitions and reset the system to get it working once again.  One could
also have the system software detect a stoppage of the data and cause a reset
to be issued.

Interestingly enough, the descrambler, which is nearly identical to the
scrambler, does NOT seem to exhibit this sort of behavior.

We will soon be using these modems in a full-duplex T1 microwave link and
will report on their performance.

<Clint>

ka7oei@uugate.wa7slg.ampr.org
clint@uugate.aim.utah.edu

------------------------------

Date: Wed, 8 Dec 1993 19:53:03 GMT
From: mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!metro!basser.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!zip.eecs.umich.edu!umn.edu!news-feed-2.@@munnari.oz.au
Subject: W9GR DSP article of Sept 1992 QST
To: ham-digital@ucsd.edu

In article <1993Dec7.184551.24853@kpc.com>, nat@kpc.com (Natarajan Gurumoorthy) writes:
|> Hi,
|>  I just stumbled across W9GR's article and am itching to build it.
|> I have several questions: 
|>  2. The article mentions that the TI assembly files for the prom code 
|> are available on compuserve. Are they also available at some internet ftp site. 
|> Any pointers would be helpful. 
|>  3. The article also mentions that the prom programming files are 
|> also available. Again pointers would be helpful.
|> 
 I found these files via anonymous ftp at nic.funet.fi. Get into
the machine and cd to directory /pub/ham/dsp/w9gr. The name of the file is
w9gr.zip. The file contains the prom programming files as well as the 
assembly sources for the lms and 3 CW filters. I located the files through
the archie server at UNL Nebraska.
 Enjoy
 Nat.

-- 
-------------------------------------------------------------------------
Natarajan Gurumoorthy AB6SJ  Kubota Pacific Computer, Inc.
nat@kpc.com    2630 Walsh Avenue
Phone 408 987 3341   Santa Clara, California 95051.

------------------------------

Date: 10 Dec 93 20:55:42 GMT
From: ogicse!cs.uoregon.edu!sgiblab!sdd.hp.com!col.hp.com!srgenprp!glenne@network.ucsd.edu
Subject: X1J at 38.4 kbps
To: ham-digital@ucsd.edu

  Since posting the basenote, I've had some very helpful and useful
exchanges with Dave Roberts, the author of X1J.  In addition, the remote
site I mentioned has been visited and the TNC running X1J was replaced
with another which has a DCD state machine.  Also, several days after
vanishing from the band, the remote X1J started functioning, poorly but
still working, again.

  In considering the differences between the remote X1J and one in the
hamshack (allright, it's really the garage) I came to the idea that
maybe what was happening wasn't due to the fundamental inability of X1J
to run fast enough. Dave's comments substantiated this.

  Due to the difference of DCD signals, the remote node had been running
full duplex.  This required limiting MAXFRAME to one but that was
tolerable.  I had set the node to FDX in order to ignore the RF derived
DCD coming from the radio which in this case can tend to have a lot of
edges due to Part 15 and other devices sharing 902-928 MHz.  However,
the radios are also designed such that RxD is qualified by DCD, even if
the TNC ignores DCD, RxD doesn't.  With a loosely set squelch and/or lots
of fast FH spread spectrum signals there can be a *lot* of edges.  With
a loose squelch the RxD line is a gated version of what the
discriminator sees (which is very noisy with a lot of fast edges in the
500 KHz bandwidth).

  I now suspect that the radio squelch was set loose and the radio could
probably hear itself weakly (noisey) during transmit.  The problem I saw
was likely the result of a tremendous number of interrupts from the
receive side of the TNC SIO (probably mostly receive aborts or errors of
some kind).  I expect that the receive interrupts have higher priority
than transmit interrupts and consequently the transmit side was able to
run out of data to send and reported underruns.

  Since replacing the TNC and disabling FDX the excessive number of
underruns disappeared and performance has returned to the same level as
that of the local X1J boxes.  The X1J code does require considerable
overhead so performance isn't stellar, but it *does* seem to run now at
38.4 kbps.  Ping RTT is about 300 milliseconds.  This is way longer than
the raw channel rate alone requires but it *does* still allow higher
speed data to go through the node and offers remote diagnostics.

  Following Dave's advice, I've disabled mheard and nodes broadcasts and
will use minqual to effectively disable NET/ROM operation.

  So, for anyone else wanting faster operation and KISS in a standalone
box for lowcost, X1J still seems viable to 38.4 kbps.  I still hope to
get a version of K3MC KISS code modified to include digipeating since I
think this might be able to run my radios much faster, perhaps in the
100-200 kbps territory. If this happens before the fullspeed controllers
are working properly I'll probably try to get that code installed in the
TNCs.

  All this is certainly trying to squeeze an underpowered platform, the
TNC2, but it is still a lot less expensive than the few alternatives,
Gracilis, the German TNC3 and perhaps the Data Engine and presently it
is more available than MIO.  I think that it points to a general issue
though; as we seek higher speeds we will continue to need to handle as
much of the "pre-filtering" in hardware as possible.  Building radio
hardware which has data which is as "qualified" as possible, along with
doing FEC in hardware rather than software may be requirements as we
push for performance.  Picking radio methods (like SS or equalization)
combined with fast hardware FEC to provide "host ready" data may be a
necessary.

 The TNC was originally designed as an interface between a "dumb radio"
and a dumb terminal.  As we've increasingly run higher levels of
complexity, TCP/IP and other networking protocols, we've drifted toward
"doing the hard part in the increasingly powerful local host.  KISS
protocol is an example of this.  However, as we turn the speed up, I
think many functions like "data cleaning" and FEC if not some of the
higher ones like switching/routing may have to be done closer to the
physical medium again.


Glenn Elmore n6gn

ax.25  n6gn@wx3k.#nocal.ca.usa.na
amateur IP: glenn@SantaRosa.ampr.org
Internet: glenne@sr.hp.com 

------------------------------

End of Ham-Digital Digest V93 #143
******************************
******************************
